OpenEdge Development:<br />Messaging and ESB Fault tolerance

Release 10.1A: OpenEdge Development:
Messaging and ESB

Fault tolerance

Fault tolerant connections allow another SonicMQ Broker to take over if the original SonicMQ Broker fails. To ensure message delivery, use the fault-tolerant APIs to setup and enable fault tolerance. These APIs include the setFaultTolerant procedure, the getFaultTolerant function, the isFaultTolerant function, the setConnectionURLs procedure, the setFaultTolerantReconnectTimeout procedure, the getFaultTolerantReconnectTimeout function, the setInitialConnectionTimeout procedure, the getInitialConnectionTimeout function, the setClientTransactionBufferSize procedure, the getClientTransactionBufferSize function, and the createChangeStateConsumer procedure. Although you setup and enable fault tolerance from the SonicMQ client, the SonicMQ Broker must support it.
Note: Fault tolerance is only available to 4GL clients running in ClientConnect and ServerConnect only.

After creating the session object, you must create the list of SonicMQ Brokers to use, set the fault tolerant property for the session, and then start the session.

The following sections contain:

Example of setting up fault tolerance

Example of a “ChangeState” handler (optional)

Example of setting up fault tolerance

The following example shows how to set up a fault tolerant session:
Fault tolerance set up
DEFINE VARIABLE sessionH AS HANDLE. 
RUN jms/jmssession.p PERSISTENT SET sessionH ("-SMQConnect"). 
RUN setConnectionURLs IN sessionH ("Primary:2508,BackupServer:9876”). 
RUN setFaultTolerant IN sessionH(TRUE). 
RUN beginSession IN sessionH. 
Example of a “ChangeState” handler (optional)

When the connection to the SonicMQ Broker is lost, SonicMQ has the ability to notify the application. A special asynchronous handler, “ChangeState” handler, notifies the client application whenever the state of the SonicMQ Broker changes. The character header property of the message passed to the “ChangeState” handler contains one of the following values: active, reconnecting, failed, or closed. You setup the handler by calling the createChangeStateConsumer procedure after to calling the beginSession procedure.

The following example shows how to use the createChangeStateConsumer procedure:
Fault tolerant example
RUN createChangeStateConsumer  
        IN sessionH(THIS-PROCEDURE, "msgHandler", OUTPUT msgH). 
PROCEDURE msgHandler: 
DEFINE INPUT PARAMETER messageH AS HANDLE.  
DEFINE INPUT PARAMETER msgConsumerH AS HANDLE. 
DEFINE OUTPUT PARAMETER replyH AS HANDLE. 
DEFINE VAR val AS CHAR NO-UNDO. 
val = DYNAMIC-FUNCTION("getCharProperty" IN messageH, "state"). 
DISPLAY val. /* val will be "active", "reconnecting", "failed", or "closed" */ 
RUN deleteMessage IN messageH. 
END. 